Overview
This section gives a summary of each of the major connection topics and includes links to more detailed descriptions where appropriate.
Connections are objects in the same sense that nodal objects are. They have member functions that allow requests to be issued to nodal objects, and once retrieved, they also provide functions that allow the event to be inspected. Connections can also be used to issue controls to their connected objects.
In most cases, connections link a provider and a consumer (except reference connections - see below). As with nodal objects, connections have attributes, and these are separated into a number of categories. In the example below, there are four attribute categories. Firstly there are attributes that determine how the object will be displayed (Appearance), secondly there are attributes that belong to the shared connection (Connection), thirdly those that belong to the consuming object (Consumer), and fourthly those that belong to the providing object (Provider). In the example below, a multiplexer is consuming from a transient store and the four categories of attributes are shown:
Connection Categories
There are five basic connection categories and these are illustrated by the following circuit definition:
Manual Connections
Manual connections provide a means of manipulating nodal objects from standard user code and as such are similar to conventional semaphore or mutex handles. They can be owned by any active object (threads, methods, call-backs or circuits) and objects can be accessed through the connection's member functions. Manual connection attributes such as timeouts, keys or rules are provided as dynamic runtime arguments to the connection's member functions. All event requests are initiated from active objects through manual or trigger connections. See Manual Connections.
Automatic Connections
Automatic connections only exist between passive objects. An example would be a connection between a collector and a store. They differ from manual connections in that their attributes are fixed at connection time.
Requests emanating from active objects through trigger and/or manual connections are propagated through circuitry along automatic connections. When the event tree is populated (all requests granted), the events are propagated back down the tree to the root consumer (active object's trigger or manual connection) where their member functions allow the event tree to be inspected. See Automatic Connections.
Trigger Connections
Trigger connections deliver events to methods and call-back functions and are actually just a special case of automatic connections. Requests are automatically issued along trigger connections at startup (when the containing circuit is activated), and after return from each subsequent execution. Each time the trigger connection's event tree is populated, an event is issued along the connection to the consuming object (method or call-back). This causes the the method/call-back to execute and the user code can then use the connection's access functions to manipulate the populated event tree. When the user code returns, the trigger connection's event tree is automatically closed and another request automatically issued. See Trigger Connections.
Reference Connections
Reference connections are not objects as such, but allow access to devices and extend connection faces so that they can be connected to from elsewhere (either through conduits/labels or externally to the circuit via circuit definition pins). See Reference Connections.
Notifications
The current release of CLIP only supports one class of notification. See AST Update Notification.